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REMARKS 

Claims 1-66 are pending in the application. 

Claims 1 -66 have been rejected. 

Claims 1,18, 35, 46, and 54 have been amended. 

Rejection of Claims under 35 U.S.C £ 101 

Claims 46-53 stand rejected under 35 U.S.C. § 101 because the claimed invention 
is purportedly directed to non-statutory subject matter. Applicants have chosen to 
overcome this rejection by amending claim 46 to recite a first MAC device coupled to a 
network. Therefore, Applicants respectfully request the Examiner's reconsideration and 
withdrawal of the rejections to these claims and an indication of the allowability of same. 

Rejection of Claims under 35 U.S.C $ 103(a) 

Claims 1-66 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
U.S. Publication No. 2003/0076781 listing Enomoto et al. as inventors ("Enomoto") in 
view of U.S. Patent 5,918,020 issued to Blackard et al. ("Blackard"). Applicants 
respectfully traverse this rejection. 

Neither the cited portions of Enomoto nor the cited portions of Blackard, taken 
alone or in combination, disclose a MAC device having the capability of receiving 
information from a client, wherein the information indicates the client is receiving data at 
too great a rate. Nor do the cited portions disclose a MAC device having the capability to 
generate a message including such information and then transmit the message. 

The cited sections of Blackard disclose a server purportedly receiving a pacing 
message from a client. See Blackard, Abstract. However, the cited portions of Blackard 
fail to disclose that the server is a MAC device. The cited portions also fail to disclose 
that the server has the capability to form and transmit a message including information 
from the pacing message. Instead, Blackard's server receives a message from a client and 
reduces the amount of data the server is transmitting. Id. Thus, Blackard's server has no 
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need for the capability to generate and transmit a message including information from the 
client, nor is the server disclosed as having such capability. 

Enomoto discloses a congestion control node configured to generate and transmit 
a congestion message to another congestion control node. See Enomoto, H [0238]. 
However, the cited portions of Enomoto fail to disclose that the node has the capability of 
receiving congestion information from a client of the node. The cited portions also fail to 
disclose forming and transmitting a message that includes congestion information 
received from a client. Instead, the cited portions disclose forming and transmitting 
congestion messages that include congestion information based on congestion of the node 
itself, and not a client of the node. See Enomoto, U [0237]. 

The cited section of Enomoto refers to Figure 1. In light of Figure 1, the cited 
section correlates Congestion Control Node Al with the first MAC device, while 
Congestion Control Node A2 performs the claimed method. But A2 does not perform any 
"receiving information..." as claimed. Instead, the congestion related information is 
purportedly generated by A2 in response to an attempt to transmit to much data on line 
L101 (LI 01 is a lOMb/s transmission line while C2 and C3 are both transmitting 8 Mb/s 
[Enomoto [0229], [0230], [0232]]). See Enomoto 1 [0239]; see also Enomoto H 
[0153]-[0154] (excessive data in transit buffer part contributes to congestion detection). 
Thus, the "receiving" limitation is not disclosed as performed by A2. 

If, on the other hand, the Office Action correlates Congestion Control Node A3 as 
performing the "receiving" limitation, then there is no disclosure of A3 performng the 
"forming" and "transmitting" limitations. So A3 cannot b econsidered the node 
performing the receiving. 

While A2 does generate congestion information that is transmitted to A3, the 
congestion information does not include an indication to A3 to change an amount of data 
transmitted to the client . Instead, A2 sends information to change an amount of data sent 
to or through A2 so that an output on LI 01 is at or below the transmission rate for that 
line. See, e.g., Enomoto 1j [0210]. Thus, the cited sections of Enomoto fail to disclose the 
"forming" limitation. 
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The cited sections of Enomoto also teach away from using information from a 
client to form a message indicating a need to reduce the amount of data transmitted to the 
client, Enomoto explicitly recites that "detection of the congestion occurrence is carried 
out in the transit buffer and detection of the congestion occurrence is not carried out in 
the transmission buffer." Id. (emphasis supplied) Thus, congestion is not detected based 
on information from a client, or even information related to a specific client. Instead, 
congestion is detected based on the amount of data stored in a transit buffer, that data 
being transferred between stations, and not the amount of traffic transferred to a 
particular client. 

Furthermore, Applicants respectfully submit that Blackard is not analogous art to 
Enomoto. Blackard is not directed to systems utilizing MAC devices or ring networks. 
Applicants respectfully submit that even if one did attempt to combine the Enomoto and 
Blackard, the resulting combination would fail to disclose a MAC device that receives 
information from a client, generates a message including that information, and transmits 
the message to another MAC device. 

However, in order to expedite prosecution, Applicants have chosen amend the 
independent claims. For example, amended independent claim 1 recites: 

A method comprising: 

receiving information indicating a need to change an amount of data being 

transmitted through a first media access control (MAC) device to a client 
of the first MAC device, wherein 

the information is received from the client when the client determines that 
the client is receiving data at a rate exceeding a set threshold; 
forming a message including an indication to a second MAC device to change a 

rate at which the second MAC device transmits data to the client, wherein 

said forming the message uses the information indicating the need to 
change the amount of data being transmitted to the client, and 

a total bandwidth allocation of the first MAC device is unaffected by said 
change; and 

transmitting the message to the second MAC device over a network. 

Applicants respectfully submit that neither the cited passages of Enomoto nor those of 
Blackard, taken alone or in combination, disclose each element of independent claim 1 . 
Specifically, the cited passages fail to teach at least the following features recited in 
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independent claim 1 : that "a total bandwidth allocation of the first MAC device is 
unaffected by said change." 

Support for this amendment is found, at least, at H [0044] of the Specification. As 
described in the originally filed Application, if, as a result of a MAC client receiving data 
at too great a rate, a MAC device associated with that client merely requests upstream 
devices to reduce the amount of data sent to the MAC device, all data directed at the 
station is reduced, not just data directed at the particular client. See, e.g., Application, \ 
[0043], This means that the total bandwidth of the MAC device, including both transit 
data and data destined for the client, is reduced. This is undesirable since it was only the 
client which was receiving data at too great a rate. The amount of transit data being 
transferred to the MAC device did not need reduced. 

Amended independent claim 1 makes it clear that while the traffic destined for the 
client is reduced, the total bandwidth of the MAC device is unaffected. Thus, the transit 
data destined for a given MAC device need not be reduced while the data destined for the 
client of that MAC device is reduced. Neither cited portions of Enomoto, nor those of 
Blackard, taken alone or in combination, disclose such capability. 

Enomoto explicitly teaches detecting congestion based on transit buffer traffic, 
having no way to determine if a client is congested, and reducing transit traffic in 
response to detecting congestion. See Enomoto, U [0237]. Blackard, as noted above, is 
non-analogous art, having nothing to do with MAC devices or their clients. Discussing 
the concept of reducing traffic destined for a client of a MAC device while not affecting 
the total bandwidth of the MAC device associated therewith does not make sense in the 
context of Blackard's system, which is oblivious to the concepts of transit buffer traffic 
versus traffic destined for a client. 

Further, Enomoto discloses no capacity to restrict data flow to an individual client 
of a Congestion Control Node. Traffic originating in a local client group of Enomoto and 
destined for a remote client is provided to Enomoto's "transmission buffer part (A 135)." 
See, e.g., Enomoto [0146]-[0150]. Enomoto's Figures 4-6 illustrate alternate 
embodiments of the "transmission buffer part" and generally illustrate that transmission 
data is classified and then inserted into an appropriate queue. See t e.g., Enomoto 

- 18- 

Application No.: 10/643,490 



PATENT 



[0168]-[0171]. Various classification schemes are presented by the referenced figures. 
Enomoto then transmits data from those queues based upon a weighting scheme that is 
disclosed to be performed on a Congestion Control Node basis. See, e.g., Enomoto 
[0172]-[0t77] (observing the "Output Adjusting Part"). Given that Enomoto is only able 
to detect and respond to congestion or a Congestion Control Node basis, and not on a per 
client basis, and the cited section of Blackard provides no disclosure of how to enable the 
devices of Enomoto to perform such detection and response, it cannot be said that the 
combination of these references anticipates or renders obvious the present claims. 

For at least the foregoing reasons, Applicants respectfully request the Examiner's 
reconsideration and withdrawal of the rejections to claim 1 and an indication of the 
allowability of same. Applicants also request reconsideration and withdrawal of the 
rejections to claims 18, 35, 46, and 54, which have been amended to include substantially 
similar limitations, and claims 2-17, 19-34, 36-45, 47-53, and 55-66, which depend 
therefrom. 

Claims 2-3, 5, 14, 19-20, 24-25, 38, 47-48 and 55-56 stand rejected under 35 
U.S.C. § 103(a) as being unpatentable over Enomoto in view of Blackard, and in further 
view of U.S. Patent 20030163593 issued to Knightly efal. ("Knightly"). Applicants 
respectfully traverse this rejection. Applicants respectfully submit that these claims are 
allowable for at least the reasons discussed above. Accordingly, Applicants respectfully 
request the Examiner's reconsideration and withdrawal of the rejections to these claims 
and an indication of the allowability of same. 



- 19- 



Application No.: 10/643,490 



PATENT 



CONCLUSION 



In view of the amendments and remarks set forth herein, the application and the 
claims therein are believed to be in condition for allowance without any further 
examination and a notice to that effect is solicited. Nonetheless, should any issues 
remain that might be subject to resolution through a telephonic interview, the Examiner is 
invited to telephone the undersigned at 5 12-439-5092. 

If any extensions of time under 37 C.F.R. § 1.136(a) are required in order for this 
submission to be considered timely, Applicants hereby petition for such extensions. 
Applicants also hereby authorize that any fees due for such extensions or any other fee 
associated with this submission, as specified in 37 C.F.R. § 1 .16 or § 1.17, be charged to 
Deposit Account 502306. 



Respectfully submitted, 




Shawn Doman 
Attorney for Applicants 
Reg. No. 60,362 
Telephone: (512) 439-5092 
Facsimile: (512)439-5099 
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